A real-time system (such as a RTPS system) is defined as a system which operates within finite time boundaries. By finite time boundaries, what is meant is that responses to system queries must occur within some predictable time boundary or response time. For example, within two seconds of the query. Response within the predictable time boundary is the overriding parameter. So, the system is not real-time in the sense that transfer of information is instantaneous, but rather that the transfer of information is in accord with some set of time sensitive parameters. Thus, a real time system is not purely asynchronous nor is it strictly instantaneous. The time boundary conditions are flexible depending on the system. For example, a radar tracking system for an anti-aircraft missile requires extremely fast response time. Whereas, a mass production assembly line in a factory may require a much reduced response time on the order of tens of minutes. Both are considered real-time under the definition provided here. Examples of real-time systems can include, without limitation, command-control systems, sensor-actuator systems, network management systems, distributed real-time simulations or games, and the like.
In the field of network applications high level protocols such as DCOM, FTP, DHCP, DCE, RTP, HTTP, and CORBA have been used for constructing commercial applications. Each of these protocols fills a specific niche and are well designed for their specific purposes. However, such protocols are found to be lacking when applied to distributing data in real-time applications. Such protocols do not provide the right level of abstraction and for the most part lack certain key functionalities necessary to create and/or implement real-time applications. In particular, such protocols do not include functionalities for achieving real-time attributes such as predictable communication, time-aware decisions and notifications, operation over unreliable transports, use of multicast, transparent hot swap substitution, or time and resource aware quality of service (QoS) controls.
The publish-subscribe communications model (also referred to herein as publish/subscribe) is a new model of network programming, whereby a message sender does not explicitly specify the receiver. Instead, the sender publishes data with a topic, while receivers who are subscribing to the topic will receive the data and possibly an asynchronous notification that the data has changed. This model is quite different from the traditional request/response programming wherein an application program explicitly indicates the service it wants and synchronously waits for a return from a blocked I/O call. The publish/subscribe model has some distinct advantages over typical server/client networks. For example, there are no special server nodes. Thus, any node can send or receive information streams from any other node. As such, publish/subscribe systems reduce the amount of system overhead required for the operation of a networked system.
Publish/subscribe communications reduce network loading and simplify programming for one-to-many network communications. It reduces network loading because there is no need for request messages, and it eliminates for polling. Finally, publish/subscribe also lets a developer make use of multicast technology where one message can be sent to many receivers. Importantly, publish/subscribe simplifies network programming because publishers do not need to know where the subscribers are on the network, and subscribers do not need to know where the publishers are. Publishers simply declare a publication topic and start sending messages. Each subscriber simply declares an interest in that topic. The publish/subscribe software takes care of all the packet addressing, data marshalling (serializing), de-marshalling, and packet-sending.
The publish/subscribe model is a natural fit for the complex communications required in distributed real-time systems. However, there are limitations to ordinary publish/subscribe systems. Ordinary publish/subscribe systems do not provide the time and resource predictability, fault tolerance, robustness and data-delivery control that real time systems require.
Therefore, an improved communication protocol is needed for facilitating real-time communications in real-time computer networks and for implementing real-time network programming applications.